In a typical legacy data processing system, firmware provides the machine instructions that control the system when the system is being powered up or has been reset, but before an operating system (OS) is booted. That is, the firmware controls the pre-OS or pre-boot operations. Firmware may also control certain operations after the OS has been loaded, such as operations for handling certain hardware events and/or system interrupts. The firmware may handle pre-boot and post-boot operations through a set of routines referred to collectively as a basic input/output system (BIOS). The BIOS thus provides the interface between the hardware components of the system and software components such as the OS.
For purposes of this disclosure, the term “firmware” is used to refer to software that may execute in a processing system before the processing system has booted to an OS, software that may provide runtime services that allow the OS or other components to interact with the processing system hardware, and similar types of software components. Traditionally, firmware was typically stored in non-volatile memory. In more recent years, however, processing systems have been developed that store firmware in, or obtain firmware from, other types of storage devices.
In addition, not long ago, a new model for an interface between platform firmware and higher-level software such as operating systems was announced. That model is known as the Extensible Firmware Interface (EFI). Version 1.10 of the EFI specification, dated Dec. 1, 2002, may be obtained from www.intel.com/technology/efi/main_specification.htm. The EFI specification defines a set of standard interfaces and structures to be provided by low-level platform firmware. Those interfaces and structures may be used for tasks such as loading additional firmware, running pre-boot applications, booting the OS, and providing runtime services after an OS has been booted.
A BIOS that was created before promulgation of, or without regard to, the EFI specification may be called a legacy BIOS. Similarly, an OS that is designed to work with a legacy BIOS may be called a legacy OS or a non-EFI-compliant OS. For example, the Windows XP® OS may be considered a legacy OS. By contrast, an OS that is able to work with an EFI-compliant BIOS may be called an EFI-compliant OS.
For purposes of this disclosure, depending upon the particular implementation under consideration, the term “processing unit” may denote individual central processing units (CPUs) within a processing system, processing cores within a CPU, logical processing units such as hyper-threads (HTs), or any similar processing resource or collection of resources to operate cooperatively as a unit. In a system where multiple processing units exist, the operating system (OS) normally owns all of the processing units.
Also, in some processing systems, it is possible to hide one or more of the processing units from the OS by modifying the advanced configuration and power interface (ACPI) tables produced by the BIOS. In some systems it is also possible to hide one or more portions of random access memory (RAM) from the OS. Additionally, in some systems, several peripheral and integrated devices can be hidden by writing bit masks to registers in the system's input/output (I/O) controller hub (ICH). These techniques may be used to hide devices for debugging purposes.
In a typical processing system, the BIOS starts booting the OS by calling a program known as the OS boot loader. For historical reasons, the OS boot loader for a non-EFI-compliant OS typically expects or requires the BIOS to switch the processor to real mode and disable address line #21 before invoking the loader. Since the pins on a device such as a keyboard controller may be numbered starting with 0, address line #21 may actually be couple to a pin labeled “A20.”
In a processing system with multiple partitions, if the first partition runs on CPU1 and the second partition runs on CPU2, switching CPU1 to real mode may not affect the second partition, as CPUs may be able to switch modes independently. However, the A20 mask output pin of the keyboard controller may be connected to all CPUs. Consequently, activating that pin may preclude all CPUs from accessing odd megabytes (MBs) of memory. Instead, if the A20 pin is active, all references to addresses within an odd MB of memory may actually get mapped over a corresponding address within an even MB of memory. Consequently, if the second partition were to execute code or access data from an odd MB of memory when the A20 pin is active or address line #21 is disabled, the processing system may map the memory reference to an incorrect location, which may ultimately result in system errors or a system crash.